\section{Future work}
In this work a relational database with academic aims was built that utilizes the ARIES family of algorithms for transaction management and recovery from unexpected system crashes.

However, it does not take into account some interesting topics like distributed transactions or long-duration ones. Those are open issues and research subjects in many universities.

For Database teaching purposes, the project can be extended showing the state of other components of the engine, like the Buffer Manager or the query analyzer. For the former, it is possible in the client to show the load and release of different pages into the Buffer Manager by currently active transactions. And for the latter, how a SQL sentence becomes a relational algebraic tree, and how the engine processes it.

One idea for future work is to extend this project by implementing some ARIES-based distributed algorithms (as D-ARIES) so that it preserves all the advantages of ARIES, like partial rollbacks and repeatable history.

Another issue of improvement could be in the Analysis phase executed in the recovery stage at system startup. One change would consist of parallelizing steps in the recovery method in order to gain performance
and efficiency. An added change could be to create a Selective Redo: not to redo those transactions that will be undone in the Undo phase (faster start-up).

An alternative is to make the system listen to incoming connections (analyze queries, create and process new transactions) at the same moment that the recovering stage is being executed.

Support media recovery (backup copies and recovery methods when the data disk is faulty).

Provide methods for deadlock detection instead of methods for deadlock prevention. 
Details for this issue can be found at section 19.2.2 of \cite{RaGh03}.
 
Build a standard JDBC connector (access to the DBMS throughout a JDBC client).

Improve the index system with the processes described in \cite{MoLe92}, \\\cite{Moha90} and \cite{Moha93}.

An interesting one is to program the ability to suspend an active transaction and resume it at some other point in time (and maybe in a different thread).
